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The aim of this work is largely a practical one. A widely employed style of programming, 
particularly in structure-processing languages which impose no discipline of types, 
entails defining procedures which work well on objects of a wide variety. We present a 
formal type discipline for such polymorphic procedures in the context of a simple pro- 
gramming language, and a compile time type-checking algorithm if which enforces the 
discipline. A Semantic Soundness Theorem (based on a formal semantics for the language) 
states that well-type programs cannot "go wrong" and a Syntactic Soundness Theorem 
states that if if accepts a program then it is well typed. We also discuss extending these 
results to richer languages; a type-checking algorithm based on if is in fact already 
implemented and working, for the metalanguage ML in the Edinburgh LCF system. 



1. Introduction 

The aim of this work is largely a practical one. A widely employed style of programming, 
particularly in structure-processing languages which impose no discipline of types 
(LISP is a perfect example), entails defining procedures which work well on objects of 
a wide variety (e.g., on lists of atoms, integers, or lists). Such flexibility is almost essential 
in this style of programming; unfortunately one often pays a price for it in the time taken 
to find rather inscrutable bugs— anyone who mistakenly applies CDR to an atom in 
LISP, and finds himself absurdly adding a property list to an integer, will know the 
symptoms. On the other hand a type discipline such as that of ALGOL 68 [22] which 
precludes the flexibility mentioned above, also precludes the programming style which 
we are talking about. ALGOL 60 was more flexible— -in that it required procedure 
parameters to be specified only as "procedure" (rather than say "integer to real procedure") 
—but the flexibility was not uniform, and not sufficient. 

An early discussion of such flexibility can be found in Strachey [19], who was probably 
the first to call it polymorphism. In fact he qualified it as "parametric" polymorphism, 
in contrast to what he called "adhoc" polymorphism. An example of the latter is the use 
of to denote both integer and real addition (in fact it may be further extended to 
denote complex addition, vector addition, etc.); this use of an identifier at several distinct 
types is often now called ' Overloading/ ' and we are not concerned with it in this paper. 

In this paper then, we present and justify one method of gaining type flexibility, but 
also retaining a discipline which ensures robust programs. We have evidence that this 
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work is not just a theoretical exercise; the polymorphic type discipline which we discuss 
here has been incorporated in the LCF metalanguage ML [2, 3], and has been in use for 
nearly 2 years. The compile-time type checker for this language has proved to be a 
valuable filter which traps a significant proportion of programming errors. 

The main body of the present paper is concerned with a technical account— both 
semantic and syntactic— of our discipline of types in the context of a simple illustrative 
language, but at this point it is helpful to characterize the approach informally. We 
outline its predominant features. 

First, everything concerning types is done at compile time; once the type checker 
(part of the compiler) has accepted a program or program phrase, code may be generated 
which assumes that no objects carry their types at run-time. This is widely accepted as 
yielding efficient object code, though it does impose constraints on the use of types 
compared with, for example, the approach in ELI [21]. 

Second, many nontrivial programs can avoid mentioning types entirely, since they be 
inferred from context. (In ML however, as in other languages, the user may—indeed 
often should— define his own types together with operations over these types. Recent 
languages which allow the user to define his own types in this manner are CLU [8], 
ALPHARD [23] and Euclid [6]). Although it can be argued convincingly that to demand 
type specification for declared variables, including the formal parameters of procedures, 
leads to more intelligible problems, it is also convenient— particularly in on-line program- 
ming—to be able to leave out these specifications. In any case, the type checker which 
we present is quite simple and could not be made much simpler even if the types of 
variables were always specified in declarations. 

Third, polymorphism plays a leading role. For example, a procedure is assigned a 
polymorphic type (which we abbreviate to polytype) in general; only when the types of 
its arguments and result can be uniquely determined from the context is it monomorphic 
(i.e., assigned a monotype). Gries and Gehani [4], among others, have made a convincing 
case for controlled polymorphic programming (in contrast with the typeless programming 
in LISP or in SNOBOL); for them however, and also for Tennent [20], the presence of 
type variables or identifiers is needed to specify polymorphic types. For us, the poly- 
morphism present in a program is a natural outgrowth of the primitive polymorphic 
operators which appear to exist in every programming language; such operators are 
assignment, function application, pairing and tupling, and list-processing operators. 
It is principally the type constraints on these operators, and in the declaration and use 
of variables, which determine for us the types of a program phrase and its subphrases. 

We do not discuss in this paper— except briefly at the end— either coercions or the 
"overloading" of identifiers. Our view is that these concepts, and also run- time type 
manipulation, are somewhat orthogonal to a compile-time polymorphic type discipline, 
and may (to some extent) be incorporated without invalidating it. 

In Section 2 we illustrate our type discipline by examples in a fragment of ML. This 
fragment should be self-explanatory, but an outline of ML is given in [3] and a full 
description appears in [2]. These illustrations should serve to make the point that we 
are able to handle useful languages. The remainder of the paper justifies the discipline 
using a very simple applicative language, Exp. The justification factors into two parts. 
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In Section 3 we define the notion of well typing (correct type assignment) and prove the 
Semantic Soundness Theorem, which says that a well-typed program is semantically 
free of type violation. If we were to give an operational definition of the language, this 
would imply that, for example, an integer is never added to a truth value or applied to an 
argument, and consequently need not carry its type around for run-time checking. In 
Section 4 we present a well-type algorithm iT and prove the Syntactic Soundness 
Theorem, which states that if it succeeds, produces a well typing of a program. We 
also give a more efficient algorithm which simulates iT* 

The types in Exp are just the hierarchy of purely functional types over a set of basic 
types. That is, the polymorphism in Exp is the natural outgrowth of a single primitive 
polymorphic operator, function application, together with variable binding. To add 
other primitive polymorphic operators, such as pairing and list-processing operators 
(as in ML), together with types built from basic ones X (Cartesian Product), list (list- 
forming), and + (disjoint sum) in addition to (function type), presents no extra difficulty 
in the two soundness theorems. Indeed, adding an assignment operator is also easy as far 
as the Syntactic Soundness Theorem is concerned, but the Semantic Soundness Theorem 
is harder to extend in this case, due to the extra semantic complication of a memory or 
store which holds the current values of assignable variables. We discuss this further in 
Section 5. 

Our work is a step towards solving the problem expressed by Morris [10] in his thesis 
as follows: ' 'to design a language and a type system in which a programmer may define 
functions whose parameters may have different types for different calls of the function." 
We recommend Chapter 4 of this thesis as a lucid introduction to the problem. Although 
Morris does not discuss the semantics of types formally, or give a polymorphic type 
system, he describes how a valid type assignment may be found for a term of the A- 
calculus by solving a set of simultaneous linear equations; we take this idea further in the 
next section. 

After doing this work we became aware of Hindley's [5] method for deriving the 
"principal type scheme' ' (which is what we call a polymorphic type) for a term in com- 
binatory logic. Hindley appears to have been the first to notice that the Unification 
Algorithm of Robinson [14] is appropriate to this problem. Our work can be regarded 
as an extension of Hindley's method to programming languages with local declarations, 
and as a semantic justification of the method. 

In summary, we present a polymorphic type discipline which is syntactically well 
understood and justified for a currently used programming language with imperative 
features, and is also semantically explained for a nontrivial, though nonimperative, 
sublanguage. 

2. Illustrations of the Type Discipline 

We illustrate our notion of polymorphism by means of some simple examples. They 
are written in a fragment of ML which we hope is self-explanatory; this fragment is 
indeed no more than Landins ISWIM [7], and we refer the reader to Burge's book [1] in 
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which he uses this style of programming almost exactly. We use no imperative constructs 
here (assignments or jumps). The constructs 

let x = e in e' , 

letf(x 1 x n ) = e in e' 

are used to give x the value of e, and to give /the value of the abstraction X(x 1 x n ) • e> 
throughout e'. For recursive functions letrec is used in place of let, and when the part in e' 
is omitted we have a declaration. 

The fully determined types (i.e., the monotypes) of ML are built from a set of basic 
types (int, tool, etc.) by the binary infixed operators x (Cartesian product), + (disjoint 
sum) and — ► (function type), and the unary postflxed operator list. Polymorphic types 
(polytypes) are obtained by admitting type variables, which here are represented by 
a, j8, y We represent arbitrary types by p, or, r. For this section we leave the meaning 
of types to the reader's intuition; it is made precise in the next section. 

Example 1 . Mapping a function over a list. 

letrec map(/, m) = if null (m) then nil 

else cons (f(hd(m)), map (/, tl(tn))). 

Intuitively, the function map so declared takes a function from things of one sort to 
things of another sort, and a list of things of the first sort, and produces a list of things 
of the second sort. So we say that map has type 

((a £) X as list) jB list, 

where a, jS are type variables. 

How is this type determined from the bare declaration of map? First, the generic 
types (we discuss * 'generic" later) of the identifiers occurring free in the declaration are 
given by 

null: a list — ► tool, 

nil: at list, 

hd: a list — > a, 
tl: a list -> a list, 
cons: (ol X a — >■ a /f& f 

that is, they are polymorphic, because their types contain one or more type variables, 
and our rule is: To every occurrence of such an identifier is assigned a type which is a 
substitution instance (substituting types for type variables) of its generic type. 

Now each of these identifiers occurs just once in the declaration, so if we denote by 
<7 id the type assigned to an identifier id we must have for some types r x t 5 , 

tfnuii = t x list — > boot, 

ffnil = t 2 list, 

^hd = ^3 list — ► t 3 , 
ffti — T 4 fii* — ► r 4 
^cons — (t 6 X r 5 Zty^) ~> t 5 list. 
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The other identifiers (map, f, m) each occur more than once, and our rules demand that 
each occurrence is assigned the same type. The rules also demand that the following 
equations are satisfied for some types p t , p % 



CT map 




at X <7 m px , 






er m — > 600/, 








°t\ 




<7m -> p 3 , 








tfmap 






^cons 




/>4 X ?5 "* Pe » 


Pi 




^nil = Pe • 



The first of these conditions relates the type of a function to those of its formal parameters; 
each of the other conditions arises from some subterm which is a function application, 
except the last, which is because a conditional expression has the same type as its two 
arms, and because the definiens and definiendum of a declaration have the same type. 

Now these equations may be solved for the variables pi , r 4 - , and aid ; Morris [10] 
discusses the solution of such equations. Indeed, the situation is entirely appropriate 
for the use of the Unification Algorithm of Robinson [14]; our well-typing algorithm is 
based upon this algorithm, and (since in this case nothing more than unification is 
needed) we may conclude from Robinson's work that the most general type of map is 
obtained, i.e., any other type a map which satisfies the equations must be a substitution 
instance of the type obtained. In fact, the solution of the above equations is 

tfmap = (y 8) X y list S list, 

where y, S are any distinct type variables. So this is the generic type of map, that is, to 
any occurrence of map within the scope of this declaration must be assigned some 
substitution instance of this type. 

These instances need not be the same. Suppose that tok is a basic type (a token being 
a sequence of characters) and that we have available the identifiers (with their types) 

tokl: tok list (a variable), 
and length: tok -> int, 

sqroot: int — ► real, two obvious functions. 

Then in the expression 

map(sqroot, map(length, tokl)) 
the two occurrence of map will have types 



((tok — ► int) X tok list) — ► int list, 
((int — ► real) X int list) — * real list. 
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Similarly, if null, for example, had occurred twice in the definition of map, its types could 
have been different instances of 

ol list -> bool 

but our rules demand that different occurrences of a formal parameter (/, for example), 
or of an identifier (map) being recursively defined, shall have the same type. 

In passing, note that the occurrences of map mentioned above can be regarded as uses 
of two separately declared (and monomorphic!) map functions, which differ only in that 
different types are explicitly provided for their arguments and results. As Gries and 
Gehani remark, the compiler could be given the task of generating these distinct declara- 
tions—or more accurately (since the programmer need not see the replication or even be 
aware of it), the task of generating different code for the body of the map function for 
use at distinct types. This would indeed be necessary in the above example if, for efficiency, 
token lists were implemented differently from integer lists (and the primitive polymorphic 
functions hd, tl etc., were correspondingly different). We are concerned with a conceptual 
framework in which these map functions may all be regarded semantically as the same 
object; then the implementor is left with the freedom to implement as few or many 
variants as he wishes. 

It is clear from our example that the rules of typing need to be carefully framed. We 
leave this task until the next section, but here we look at one more example to illustrate 
what happens when let or letrec is used locally. 

Example 2. Tagging. Suppose we want a function tagpair, such that tagpair (a) is a 
function under which 

(ft, c) k+ ((a y ft), (a, c)). 

Of course, we can easily write 

let tagpair(fl) — A(ft, c) • ((a, ft), (a, c)). 

Now we can explain, without setting up equations, how our well-typing algorithm 
tackles this declaration. It first assigns "unknown" types (i.e., type variables) a, ]8, and y 
to a, ft, and c. Then ((a, ft), (0, c)) acquires type (a x jS) x (a X y), and the A-expression 
acquires jS x y (a X jS) X (a X y); finally tagpair acquires 

«-*0Xy->((*Xj3)X(«Xy)) (*) 

(no type equations have placed any constraint upon the types of a, ft, and c). 
But consider another way of defining tagpair, using the (infixed) function 

#: («-/J) x ( y -8)-((a Xy)-*(/J X 8)) 

such that (/ # g)(a y c) ~ (/ (a), g(c))> and the pairing function 

pair: a (jS -> a x j8) 
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such that pair(a)(6) = (a, b). We could write 

let tagpair = Xa • (let tag = pair(a) in tag # tag) 

We might then expect the well-typing algorithm to proceed as follows. First, ot is assigned 
to a. Then, using the generic type of pair, pair(a) acquires S^axS. This is then used 
as the local generic type of tag, and the two occurrences of tag in tag # tag are assigned 
/? -> oc t X jS, y — ► <x 2 x y, respectively. The occurrence of # is assigned an instance of 
its generic type (again using new type variables) and the type equation for function 
application will cause the type 

P X Y («i X j8) X (oc 2 X y) 

to be assigned to tag # tag, and to the body of the A-expression, so that tagpair acquires 
the type 

^(^y-^XflxKxy)). (**) 

Now comparing (*) with (**), something has gone wrong; the second type is too 
general. The problem is that tag and its generic type depend upon the A-bound variable a 
and its type a, and we do not allow different bound occurrences of a A-bound variable 
to have different type. Indeed, as far as type is concerned, we should get the same as if 
tagpair were defined in yet a third way, by 

let tagpair = Xa • (pair(tf) # pair(tf)) 

and the reader may be able to obtain (by setting up some equations as in Example 1) the 
expected type (*) in this case. 

The solution is fortunately straightforward. We decree that in instantiating the type 
of a variable bound by let or by letrec. only those type variables which do not occur in 
the types of enclosing A- bindings (or formal parameter bindings) may be instantiated. 
We call such instantiate variables (in a generic type) generic type variables. 

Now in the second definition of tagpair, the locally defined tag acquired a generic 
type 8 -> a X S, in which S is generic but a is not. Thus a should not have been instan- 
tiated in assigning types to the occurrences of tag, and then (**) would have been identical 
with (*). This example may appear a little contrived; indeed, our experience has been 
that almost always either all or none of the type variables of a generic type are generic. 
But there seem to be no simple syntactic constraints which would eliminate the excep- 
tions, nor does it seem desirable to do so. 

From the examples it becomes clear that the rules for typing variables bound, respec- 
tively, by let (or letrec) and by A are going to be different. Thus, although our semantics 
for the two expressions 

letx = e in e'\ (Xx • e')e 

may be (and are) equivalent, it may be possible to assign types correctly to the former 
but not to the latter. An example is the pair 



letl^Xxx in 1(1); (XI • I(I))(Xx ■ x). 
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A (partial) intuition for this is that a A-abstraction may often occur without an argument; 
the second expression above contains a special (and rather unnecessary) use of abstraction, 
in that an explicit argument— (Ax • *)— is present. Since the let construct (when translated) 
involves this restricted use of an abstraction, it is not unnatural that its rule for type 
assignment is less constrained. A compiler could, of course, treat all explicit occurrences 
of (Xx - e')e in the less constrained manner. 

The treatment of types in the interaction between A-bindings (i.e., formal parameter 
bindings) and let bindings is really the core of our approach. It gives a consistent treatment 
of the nonglobal declaration of a procedure which may contain, as a free variable, a 
formal parameter of an enclosing procedure. This appears to be one of the more crucial 
difficulties with polymorphism, and therefore we feel justified in presenting our analysis 
in terms of a simple language (Exp) which excludes as much as possible that is irrelevant 
to the difficulty. 

The reader may still feel that our rules are arbitrarily chosen and only partly supported 
by intuition. We certainly do not claim that the rules are the only possible ones, but the 
results given later demonstrate that they are semantically justified. In fact, we show that a 
program which admits a correct type assignment cannot fail at run-time due to a type 
error— or more precisely, that type constraints encoded in its semantics are always 
satisfied. It follows from this that compile-time type checking (i.e., the attempt to discover 
a correct type assignment) obviates the need to carry types at run-time, with an obvious 
gain in the efficiency of implementation. 

This is of course a principal aim in compile-time type checking; another is the early 
detection of programming errors (many of which result in ill- typed programs). Our 
achievement is to extend type checking to embrace polymorphism. Moreover the type- 
checking algorithm in its final form (Algorithm f in Section 3) is remarkably simple, 
even though the proof of the Syntactic Soundness Theorem, which states that— if it 
succeeds— it produces a correct type assignment, is rather tedious. 

We would like to give an independent characterization of the class of programs which 
can be well typed in our system, but we have no idea how to do this. However, we can 
give some pointers. At the suggestion of a referee we looked at Burge [1, Chapt. 3] 
concerning general functions for processing data structures. All of the functions there 
(with the exception of Section 3.11 which we did not examine) acquired the expected 
types from the ML type checker after they had been modified in two respects. First, 
Burge leaves implicit the coercion functions between a disjoint sum type and its summand 
types; we needed to make these explicit (this point was mentioned in our Introduction). 
Second, we used the ML abstract type construct (see Section 5 for an example) to 
formulate the recursive type definitions used by Burge. In this construct, the isomorphism 
between a defined abstract type and its representation is made explicit and must be used 
explicitly. To see the need for this requirement consider the case of an a-stream, which 
is defined to be a function which yields a pair consisting of an a and an a-stream. The 
type equation 

a-stream = > (a x a-stream) 

cannot be solved by unification (unless we allow infinite type expressions). But by 
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treating the equation as an isomorphism, and using two functions to convert back and 
forth between an abstract type and its representation, this difficulty is removed. We 
claim that this solution is in keeping with the notion of abstract type (see [8], for example). 

On the negative side, there are certainly useful expressions which we cannot well type, 
though we are not clear how burdensome it is to do without them. An obvious example 
is Curry's Y combinator. 

F = V (A* -/W*))X^ •/(«(*))) 

since self-application is ill typed for us. But letrec avoids the need for F. More practically, 
consider 

h*FU)=K«, b) ■(/(-),/(*)) 

which— it may be argued— should accept as argument a function which is polymorphic 
enough to operate upon a and b of different type. For example, 

,F(reverse)(#, y) 

produces a pair of reversed lists of different type if x and y are lists of different type. 
Our system rejects such a use of F (since it requires a and b to have the same type), but 
admits 

let reversepair = X(x t y) • (reverse(jc), reverse^)) 

or any other specialization of the function argument of F. 

We feel that this example illustrates the main limitation of our system, but that we 
may have kept as much flexibility as is possible without the use of explicit type parameters. 
When these are introduced, the problem arises of the type of types; Reynolds [12] has 
made some progress in solving this problem, but we were anxious to see how much 
could be done while avoiding it. 

3. A Simple Applicative Language and Its Types 

3.1 . The Language Exp 
Let x range over identifiers, that is 

xe Id. 

Then the expression language Exp is generated by the following grammar: 

e ::= x \(ee')\ if e then e* else e" \ 

Xx • e | fix x - e | let x = e in e'. 

Here (ee f ) means application, fix x - e stands for the least fixed point of Xx • e, and the 
last clause binds x to the value of e throughout e\ We often use d, e,f— with primes and 
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suffixes— to range over Exp. Constants are omitted; we can imagine instead some standard 
bindings for certain identifiers in an initial environment. 

We give an ordinary denotational semantics for Exp, in which we include a value 
4 4 wrong," which corresponds to the detection of a failure at run-time. In this small 
language, the only failures are the occurrence of a non- Boolean value as the condition 
of a conditional, and the occurrence of a nonfunctional value as the operator of an 
application. 

Our semantic domains may be taken to be complete partial orders (epos); a cpo Z> 
(see [9]) is a partially ordered set such that (a) there exist a minimum element, ± D , 
(b) every directed subset of D has a least upper bound in D. Take as given a set {B { } of 
basic domains, with B 0 = T, the three element truth value domain 



true false 




and we define recursively 

V = #o + ^i + + F + W (disjoint sum of domains, with 

J_ r adjoined as minimum element), 
F = V -> V (continuous functions from V to V), 

W = { • } (error). 

The solution (up to isomorphism) of such a set of domain equations is assured by Scott 
[15]. Although he worked with complete lattices, the solution also exists in epos (see 
Plotkin [11]). 

The semantic function is $ e Exp — ► Env -> F, where Env = Id V % the domain 
of environments. We use r\ to range over Env. In denning and later, we use some 
familiar notation of Scott and Strachey [16], illustrated by these examples (where D is 
some summand of V): 

(i) UdeD, then d in V is the image of d under the injection of D into V. 

(ii) If v e V % then 

v E D = true if v = d in V for some d e D, 

= ±T if V = Lv> 

= false otherwise. 

(iii) If v e V, then 

v | D = d if v = d in V f for some de D> 
= _Ld otherwise. 
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The environment vf = -q{vjx} is identical with y except that if(x) = v. The value • in V 
{-eW) is written "wrong." We require the conditional function COND eT-> V 
V-+ V, where COND tvv' is written t-^v,v' and takes the value 

v if t = true, 
v' if / = false, 
-Lv if t= ± T . 

3.2. Semantic Equations for Exp 

In these equations, the open brackets [ ] indicate syntactic arguments. 

tflMh =v 1 EF->(v 2 EW^ wrong, {v x \F)v 2 ) y 
wrong 

where v t is ^ie^n (i ~ 1, 2). 

^W*i *^ ^2 ^ ^l 7 ? = v i E #o I #o ^2 > wrong 

where ^ is <?[e t -]fo (* = 1, 2, 3) 

<f [A* • ejr? = (Xv • £{e\ r^v/x}) in V 

Slfix x -ejrj = Y(\v • g\el ri{vjx}) 

${let x = e ± in e 2 \q = v t E W wrong, S\e^\ rjivjx} 
where v x = &le^q. 

Notes, (i) Y is the least fixed-point operation. In many languages the emfixf-e 
would be restricted to be an abstraction Ay • e\ and then 

letf = fixf-(\ye') 

might receive the syntax 

let recf(y) = e' 

(ii) It is easy to see that "let x = e x in e 2 has the same meaning under $ as 
*'(A# * e 2 )^i" • But part of our aim is a type discipline which admits certain expressions in 
the first form and yet rejects their translations into the second form; this is because A- 
abstractions may in general occur without an explicit operand, and need more careful 
treatment. 

(iii) The semantics for (e x e 2 ) corresponds to call-by- value, since the test "v 2 E W" 
ensures that the meaning of {e x e 2 ) is J_ F if the meaning of e z is J_ r . The omission of 
this test gives a call-by-name semantics (a similar test may be omitted in the semantics of 
the let construct), and the Semantic Soundness Theorem goes through equally in this 
case. 
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33. Discussion of Types 

We now proceed, in outline, as follows. We define a new class of expressions which 
we shall call types; then we say what is meant by a value possessing a type. Some values 
have many types, and some have no type at all. In fact "wrong" has no type. But if a 
functional value has a type, then as long as it is applied to the right kind (type) of argument 
it will produce the right kind (type) of result— which cannot be "wrong"! 

Now we wish to be able to show that— roughly speaking— an Exp expression evaluates 
(in an appropriate environment) to a value which has a type, and so cannot be wrong. 
In fact, we can give a sufficient syntactic condition that an expression has this robust 
quality; the condition is just that the expression has a "well-typing" with respect to the 
environment, which means that we can assign types to it and all its subexpressions in a 
way which satisfies certain laws. 

So there are two main tasks, once the laws of type assignment are given. The first— to 
show that an expression (or program) with a legal type assignment cannot "go wrong"— 
is tackled in this section; surprisingly enough, it is the easier task (at least for an applicative 
language). The second task is to discover a legal type assignment, given a program with 
incomplete type information. This task is often called type checking. Of course, this term 
can also mean just verifying that a given type assignment is legal; in a practical situation 
we probably require something between the two, since one cannot expect a programmer 
to attach a type to every subexpression. In Section 4 we look at the class of legal type 
assignments for a given program (the class is infinite in general, since we admit poly- 
morphism), and we give an algorithm which, if it succeeds, produces a legal type assign- 
ment. We conjecture that if the latter exists then the algorithm finds one which is most 
general, in the sense that any other legal type assignment is a substitution instance of it 
(substituting types for type variables). 

3.4. Types and their Semantics 
The syntax of types is as follows. 

(1) t 0 , are (basic) types; one for each i? f . 

(2) There is a denumerable set of type variables, which are types. We use a, jS, y,... 
to range over type variables. 

(3) If p and a are types, so is p -> a. 

A monotype is a type containing no type variables. We use /x, v, 77,... to range over 
monotypes. We use the word poly type when we wish to imply that a type may, or does, 
contain a variable. 

We first give the semantics of monotypes; that is, we give the conditions under which 
a value ve V possesses a monotype fi y which we write v : ^. 

(i) v : i t iff v = \_ v or v E B. t 

(ii) v : (a -> v iff either v = _\_ v , or v E F and (v \ F)u : v whenever u : jjl. 
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It is clear then that many values have no type. Examples are 
wrong, (XvsV - wrong) in V, 

(Xv g V * v E B 0 (v | B 0 -> x in V, y in V\ wrong) in F 
(where x e B x , y e B 2 for example). 

But in the last example if y e 2?j instead, then the function has type t 0 -> i x (and no 
other). 

Some values have many types; the identity function 

(XveV-v)m V 

for example has type /x /x for every /x. And of course J_ F has every type (it is the only 
value which has every type). 

This notion of type is derived from Scott [17]. In fact, it is what Scott calls functionality 
(after Curry), and is distinct from the notion of a retract. If we temporarily identify a type 
with the set of values which possess it, then it is easy to show that types are downward 
closed and directed complete, that is 

(i) Vv, v' e V - (v : fx and v' c v) => v' : /x, 

(ii) For each directed subset X of V 9 (Mv e X • v : it) => U X : xt. 

Retracts share the second property, but not the first. Recently Shamir and Wadge [18] 
have defined a type to be any set with these two properties, and they investigate the 
consequences of identifying a value v with the type {v* \ v' ^ v}. 

The semantics of polytypes is as follows. First, we use p < a to mean that p may be 
obtained from a by substituting types for type variables ( < is clearly reflexive and 
transitive). For example, 

ix — * /x a — ► a ^ — * j8 <J a — ► /?, 

but 

a 0 < j8 -* 0 (unless * = £). 

Then we define 

t; : o- iff V/x < a • v : /x. 

For example, 

(Xv • v) in F : a — > a. 

Polytypes thereby also stand for subsets of V, and these are also directed complete. The 
reader may like to think of each type variable in a polytype as universally quantified at 
the outermost; for example, 

a — ► a "means" Va * a — > a, 

where the bound a ranges over monotypes. In fact, it is because a here ranges over 
monotypes (not all types) and because we do not admit expressions like 

(Va * a — ► a) — ► (Va • oi — ► a) 
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as types— though we can see they "mean" if the bound variables are taken to range over 
monotypes— that we avoid the difficulties (and also some of the interest) of Reynolds [12] 
in his richer notion of type. 

We need the following simple properties, which are immediate from our definitions. 

Proposition 1. If v :a and t < a then v : r. 

Proposition 2. Ifvia^r and v' : a, then (v \ F)v' : r. 

In each case, a property of monotypes is lifted to polytypes. 

3.5. Type Assignments 

To prepare the ground for the theorem that well-typed expressions cannot "go wrong," 
we need to define what is meant by typing an expression. We need first some notion of 
a type environment to give types to the free variables in an expression. 

A prefix p is a finite sequence whose members have the form let x, fix x, or Xx, where x 
is a variable. A prefixed expression (pe) has the form p | e, where every variable free in e 
occurs in a member of p. We separate the members of a prefix by a period ( *). 

Every pe has sub-pe's given by the following, together with transitive reflexive closure: 

(i) p | x has no sub-pe's except itself, 

(ii) p | (ee') has sub-pe's p | e and p | e' , 

(iii) p\{if e then e' else e") has sub-pe's p \ e, p \ e' and p \ e" , 

(iv) p | (Xx • e) has sub-pe p - Xx \ e, 

( v ) P ! (fi x x ' e ) nas su b-pe p • fix x e, 

(vi) p | (let x — e in e') has sub-pe's p j e and p ■ let x \ e\ 

For example, Ay | (let f = Xx • (xy) in (fy)) has sub-pe's (besides itself) 

Ay j Xx - (xy), Xy - Xx \ (xy), Xy • Xx \ x, Xy ■ Xx \ y, 
Xy - letf | (fy), Xy ■ letf\f y Xy ■ to/ | y 

so a sub-pe is just a subexpression prefixed with all the variable bindings which enclose it. 
Note that Xx • (xy) in the above is not enclosed by let f— it is not in the scope of this 
binding. 

We say that a member let x or fix x or Xx of p is active in /> j ust if no # occurs to the 
right of it in p. 

Now a fy/)m£ of a pe /> | e is an assignment of a type to each element of p, and to each 
subexpression and each Xx, fix x, or let x in e, with the constraint that in a subexpression 
(let x = e' in e") the same type is assigned to let x and e'. Thus one typing of the illustrated 
pe (it is nearly, but not quite, a well typing in the sense later defined) is as follows: 

(/(^y)->v%)v)v • 

We denote a typing of p | e by p | or by j> | ^ CT when we want to indicate the type u 
assigned to e itself. 
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In any p | e y and any binding let x a in either p or e, a type variable in a which does not 
occur in (the type of) any enclosing \y r or fix y r binding is called a generic type variable 
for the binding let x a . In the example above, ft is generic, but oc is not, for the binding 
to Accrue • Intuitively, the generic type variables in a binding to x a represent degrees 
of freedom for the types at which x may be used; they represent the local polymorphism 
of x. Notice that if no A or fix bindings enclose let x a , then all the type variables in a are 
generic. A generic instance of a is an instance of a in which only generic type variables are 
instantiated. 

For technical reasons we require that generic type variables occur in a controlled 
manner. We say that p \ 3 is standard if for every typed sub-pe p' \ 3' (with induced 
typing) the generic type variables of each member let x a of p' occur nowhere else in 
p f | 3'. Thus in particular, if let x p = e p in e a is a subexpression of 3 y with induced typing, 
then the generic type variables in p may not occur in e a (though they must of course 
occur in e p ). 

We now define the notion of a well-typed (wt) pe as follows: 

(i) p | x T is wt iff it is standard, and either 

(a) Xx T or fix x T is active in p> or 

(b) let x Q is active in p y and r is a generic instance of a. 

(ii) p | {e p e a ) r is wt iff p \ e and p | e are both wt, and p = a -> r. 

(iii) | (*/ e p ^ eke e" a \> is wt iff j> | e y p \ e' and p \ e" are all wt, p = t 0 , and 
a - r — r\ 

(iv) j> | (Xx p • e a ) r is wt iff p • Xx p | e is wt and t = p — > a. 

(v) p | (^ # p ■ e a ) T is wt iff p ■ fix x p \ e is wt and p = cr = t, 

(vi) ^ | (/e£ # p = e p in e a ) T is wt iff p | e and j> • /eJ # p | e" are both wt, and a = r. 

Although this recursive definition is useful for some proofs, an alternative charac- 
terization of wt is sometimes useful. The proof of the next proposition is fairly straight- 
forward, and we omit it. Note that a wt p \ Sis necessarily standard, by an easy structural 
induction. 

Proposition 3. p | 3 is not iff the following conditions hold: 

(A) It is standard. 

(B) For every {bound) occurrence x a , the corresponding binding occurrence is either 
hc a , or fix x a , or let x r , where a is a generic instance of r. 

(C) The following conditions hold for all subexpressions {with induced typing) of 3 

{e P e a )r P = <r ^ r, 

(if e p then e' a else e" r )s p = r 0 and a = r = t', 

(Xx 0 • e a ) r t === p > o> 

(fix x p -e a ) T p = (7 = T, 

(let * p - e p m ^) T (t = r. | 
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The typing which we illustrated above therefore fails to be wt for only one reason: 
The subexpression (/( a -> v )-*yjO v violates the first of conditions (C) in Proposition 3. 
Consider another example. The following (with p empty) is a well typing: 

letl a ^ = (Xx a • xX+*in 

Note that a is generic in the type a -> ot of the declaration of /, so may be instantiated 
(possibly differently) in the types of bound occurrences of /. 

To illustrate the need to instantiate only generic type variables, for variables declared 
by let, notice first that in Xx a ■ x Q we must have a = ]8, by condition (B) of Proposition 3. 
Indeed, we can argue intuitively for this as follows: if we declare 

let I = Xx • x in 

then we wish to have that any expression (le) in the scope of this declaration receives the 
same type as the subexpression e. But now suppose we write (with assigned types) 

let 4^ - (A* a • (lety a - x a in y B ) B ) a -n « • ■ 

then— since this is semantically equivalent to the simpler declaration— we should again 
demand that a = jS. But this is imposed in our definition of well typing, just because ot 
is not generic for the binding let y a , so may not be instantiated in a bound occurrence 
of y. 

3.6. Substitutions 

A substitution S is a map from type variables to types. S may be extended in a natural 
way to yield a map from types to types, from typed pe's to typed pe's, etc. 

We say that 5 involves a type variable ot if either Sot =£ ot, or for some jS ^ a, a e 
(a g t means a occurs in r.) 

We need substitutions extensively in the second part of this paper, but for the present 
we need only one property relating substitutions and wt. 

Proposition 4. // S involves no generic variables of awtp\3, then S(p \ 3) is also a wt. 

Proof. We use Proposition 3. First, observe that the assumption on S yields that 
the generic variables for each binding in S(p | 3) are exactly those for the corresponding 
binding in p | 3. Since SjS contains no generic variable when j3 is not generic, S(p | 3) is 
standard. 

Second, if x a is bound by Xx a or fix x c in p \ 3 y then x Sa is bound by Atf^ or fix x Sa in 
S(p | 3). If x a is bound by let x T , and a = [pi/o^ pw/aj-n where a i are the generic 
variables of r, then in S(p \ 3) x Sa is bound by let x St , and Sv = [Sp 1 ja 1 Sp n lo> n ](Sr) 
is a generic instance of St. 

Third, conditions (C) of Proposition 3 are easily verified for S(p | 3) y using identities 
like S(a t) = 5a -> Sr. | 
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3.7. Well-Typed Expressions Do Not Go Wrong 

First we need a simple relation between semantic environments 77 and our type en- 
vironments—which are typed prefixed p. We say 

77 respects p iff, whenever let x p or Xx p or 
fix x p is active in p, rj{xj : p. 

Theorem 1 (Semantic Soundness). If 77 respects p and p\ 3 T is well typed then 
A#? : r. 

Proof. A fairly simple structural induction. Take the six cases for <7 T . 

(i) x T . Then either Xx T or fix x T is active in p> and 7]{xJ : r, so &[x}q : r, or # CT 
is active in p y and 77M : o\ but then t < a, so <^M^ = r\\x\ : r, by Proposition 1. 

(ii) (e a + T e a ) r . Then p \ e a ^ T is wt, so S\e\q : 0 — ► r, and similarly #[^]^ : ct. Then 
from the semantic equation (remembering that wrong has no type) and by Proposition 2 
we get #ld}q : t. 

(iii) (if e lQ then e Q else el). Straightforward; the only extra detail needed here is that 
J_ v has every type. 

(iv) (Xx p - e a ) p + a . Then p • Xx p | e a is wt. Now we require (Xv • <S\e\ 7}{vlx}) in V 
: p ~> a. Denote this function by / in V. The inverse of Proposition 2 does not hold, 
that is, to show / in V : p — >■ 0 it is not sufficient (though it is necessary) that whenever 
v : p,fv : a. What is required is that for every 77 -> v < p -> <r,/in V : p, ->- v. 

Suppose then that [i~+v ^ p — ► o\ Then there is a substitution S, involving only the 
type variables in p and a, such that \l -> y = £(/> -> <r). Then, since none of these type 
variables is generic in p - Xx p \ e a , it follows that S(p) • | £(tf)i, is wt by Proposition 4. 
Moreover 77 respects S(p) (since by Proposition 1 whenever rjlxj : 0' and r < a', 77M : r') 
so for any v : p, we also have y]{vjx} respects £(/>) - Xx u . 

It then follows by induction that S\e\ rj{vjx} : v, so we have shown that v : p, implies 
fa : v, and this yields /in V : \l -* v as required. 

(v) (yue # p • £ p ) p . Then p ' fixx p \e Q is wt. Now we require that z; : p, where 

* = Y(Xv' -gleUiv'jx}). 

Now © = , where z> 0 = ± v , = &\e\ r){v i lx} y and by the directed completeness 
of types we only have to show v t : p for each L 

Clearly v 0 : p. Assume v t : p. Since 77 respect p y we have that rrfVijx} respects p • fix x p , 
so by the main induction hypothesis v i+1 : p also, and we are done. 

(vi) (let x ^= e p in e 0 ) 0 . Then p \ e p is wt, so we immediately have v : p, where 
v = <f W77. We require <?f*'J 77^/*} : a. 

Now • /e£ x p I e£ is also wt, and because v : p we have that rj{olx} respects ^ • /e£ # p ; 
the rest follows by the induction hypothesis, j 
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As a corollary, under the conditions of the theorem we have 

Mtj # wrong, 

since wrong has no type. 

4. A Well-Typing Algorithm and Its Correctness 

4.1. The Algorithm HT 

In this section we tackle the question of finding a well typing for a prefixed expression. 
We present an algorithm iV for this. We would like to prove that is both syntactically 
sound and (in some sense) complete. By syntactic soundness, we mean that whenever iV 
succeeds it produces a wt; by completeness, we mean that whenever a wt exists, HT 
succeeds in finding one which is (in some sense) at least as general. 

Although W is probably complete, it is difficult to find a simple proof. So we con- 
centrate on soundness, and then comment on implementation of iV and on extending 
it to deal with richer languages. Since a type-checking algorithm which simulates iV has 
been working successfully for nearly 2 years in the context of the LCF metalanguage 
ML [2], we have evidence for its usefulness and even—to some extent— for its com- 
pleteness. 

IV is based on the unification algorithm of Robinson [14]. Indeed, the only feature of 
well typing which does not fall directly within the framework of unification is the condi- 
tion that t should be a generic instance of a whenever x r is bound by let x G . The com- 
pleteness (in some sense) of *W should follow from the second part of the following 
proposition concerning unification, but we need only the first half for our proof that 
is sound. 

Proposition 5 (Robinson). There is an algorithm °ti, taking a pair of expressions 
{over some alphabet of variables) and yielding a substitution, such that for any pair of 
expressions a and r 

(A) J/^(a, r) succeeds, yielding U, then U unifies a and r (i.e., Uo = Ut). 

(B) 7/ R unifies a and r, then °U(p, t) succeeds yielding a U such that for some sub- 
stitution S 9 R = SU. 

Moreover, U involves only variables in a and t. 

To find a well typing of a complete program/, we would expect to supply also a typed 
prefix p, containing only let bindings, giving the types of values bound to predefined 
identifiers. We would then expect iT to yield / such that p \ f is a wt. 

To state (and prove) iT recursively however, prefixes containing all types of binding 
occur, and W in general needs to modify the nongeneric type variables in the prefix to 
meet constraints imposed on the program. We therefore make iT return also a sub- 
stitution J*, indicating the necessary transformation. 
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To be precise, we show that if W (p 9 /) succeeds and returns (T 9 f) 9 then ( Tp) | / is a wt . 

We first state if. At certain points W requires type variables which have not previously 
occurred; such new type variables are denoted by P or p t . i^(p 9 /) is defined by induction 
on the structure of /; the algorithm is expressed in a purely applicative programming 
style, in contrast with the more efficient algorithm J presented later, which is expressed 
more in the style of imperative programming. 

Algorithm W 

iT(p,f) = (TJ) 9 where 

(i) If /is*, then: 

if Xx a or fix x a is active in p then 

T=IJ=x a ; 
if let x a is active in p then 

T=IJ=x r 
where r = [ft/ojcr, are the generic variables of or, 
and fa are new variables. 

(ii) If /is (de) 9 then: 

let (R, 3 P ) - HT(p t d) 9 and (S 9 e a ) - iT(Rp 9 e)\ 

let U = <%(S P , a -> 0), j8 new; 

then r = t/S#, and / = U(((S3)e) B ). 

(iii) If / is (if d then e else <?'), then: 

let (R, 3 0 ) = 1T(p, d) and U 0 - t 0 ); 

let (5, *.) = #"( l^RR e), and (5', £,) - 1T(SU 0 Rp 9 e'); 

let t/ = 4r(S'or, a'); 

then T - US'SU 0 R, and 

/ = £/((*/ s"st/ 0 3 c/w 

(iv) If /is (A# • d) 9 then: 

let 3) = i^(p ' *x 8 , d) y where j8 is new; 
then T = R 9 and/ = (A*^ ■ Z,)^, . 

(v) If / is (fix x ■ d) 9 then: 

let (R 9 3 P ) = iT(p 'fixx py d) 9 p new; 
let U = <%(Rfa p); 

then r = C/i?, and / = (fix x URQ • C/J)^ . 

(vi) If /is (Ztf x ^ din e), then: 

let =lT(p 9 d); 

let (S,*,) =iT(Rp -ta* 09 e); 

then 7 1 = Si?, and / - (&i * Jp = S3 in *) a . | 
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4.2. The Soundness of if 

To show that if is sound it is convenient to have a few simple definitions. 
If A is a type, a typed prefix, or a typed pe then 

Vars(^4) -{a|ae^,aa type variable). 

If A is a typed prefix or a typed pe then 

Gen(^) d ~{ a | a ei,aa generic type variable}, 
Spec(^) = f Vars(^) - Gen(^). 

If S is a substitution, then 

Inv(£) = f {a [ S involves a} 

= {a | 30 • Sj8 =^ j8 and a e {£} u Vars(5j8)}. 

We need the following simple properties, whose proof we omit: 

Proposition 6. (A) Inv(RS) C Inv(jR) u Inv(S) 
(B) Vars(5r) C Vars(r) u Inv(S). 

Theorem 2 (Syntactic Soundness). Let p be a standard prefix, and p\f a (closed) pe. 
Then,ifif(pJ)=(Tj T l 

(A) Tp\fiswt, 

(B) Inv(T) C Spec(p) U New, 

and 

(C) Vars(r) C Spec(£) U New, 

where New is the set of new type variables used by if. 

Proof. By induction on the structure of /, using the recursive definition of wt. We 
omit the cases of conditional andybc expressions, since nothing new arises there, and we 
treat the easier of the other cases first 

(i) / is x. Then T = /, so (B) is immediate. If Xx a or fix x a is active in p then 
f = x a and (A), (C) are immediate. 

If let x a is active, then / = x r , where r = [ft/aja, {aj generic in a, New — {&}. Then 
Tp | / = p | x T is standard and (A), (C) follow easily. 

(iv) / is (Ax • d). Let <7 P ) = if(p • Xx 0 , using new variables New x , say. 
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By induction, R(p • Xx 0 ) \ 3 P is wt, so for (A) / = Rp \ (Xx R0 • 3) R ^ P is wt (def n of wt). 
Also by induction, 

= Spec(^) U {£} U Newj 

= Spec(^) U New (since New = New x U {£}) 

and (B) follows since T = R. For (C) 

Vars(J?j8 -* p) C Inv(J?) U {jS} U Vars(p) by Proposition 6, 
C Spec(p) U New 

as required. 

(vi) / is (let x = din e). Then let (R, 3 P ) = ^(^, d) y using new variables iVes^ , 
say. Then by induction 

Rp\3\$vft (1) 

v2)| £S P ec ^ uNe ^ (2) 

Now from (2) 

Spec(#£) C Inv(J?) U Spec(^) 

C Spec(p) U New x (3) 

and from (1) by standardness 

Gtn(Rp | 3) n Spec(i^) = 0 . (4) 

We also have that Gen(i^p) = Gen(p), which is disjoint from Vars(p) by (2), hence 
.Rp • let x p is a standard prefix. 

So let 5, e a = ^(i?/ • to * p , *) using new variables New 2 . Then by induction 

S(Rp • letx p ) | e is wt (5) 

Vaja)! C S P ec (*^ ' to **) U New * (6) 

But Spec(#£ • to * p ) = Spec(#£), so putting (6) and (4) together yields (since New 2 
are new variables) 

Inv(S) n Gcn(Rp | 3) = 0 

and it follows by Proposition 4 that S(#£ | 2) is wt, and using (5) we have by definition 
of wt that 

SRp i (let x Sp = in 



TYPE POLYMORPHISM 369 

is wt; but this is just Tp | /, so we have proved (A). For (B), we have 

Inv(T) C Inv(S) U Inv(fl), by Proposition 6, 

C Spec(p) U New x U New 2 , using (6), (3), and (2) 

and for (C), by similar reasoning, 

Vars(a) C Spec(£) U New x U New 2 . 

This is all we need, since New — New x U New 2 in this case. 

(ii) / is (de). Let (R, <? 0 ) = W(p, d), using new variables New 1 , and (5, e a ) = 
if(Rp y e)> using new variables iWw 2 ; then by similar reasoning to case (vi) we find that 



SRp | S(3 P ) is wt (7) 

SRp | * CT is wt (8) 

Now if U = ^(iSp, a — ► J8), where jS is new, we have by Proposition 5 that 

USp=Ua^Up, (10) 

Inv( U) C Vars(Sp) U Vars(a) U {£}. (11) 



It follows that U involves no generic variables of the wt's (7) and (8), and that 

USRp\U(({S3)e)e) 

is wt; but this is just Tp | /, so we have proved (A). For (B), we have first that 

New = New x u New 2 U {/}}, 

so 

Inv(T) C Inv( I/) U Inv(Si?), by Proposition 6, 
C Spec(p) U New, from (9) and (1 1), 

and for (C), 

Vars(r) = Vars(l/j8) 

C lnv(U) U {£}, by Proposition 6, 

C Spec(p) U New, again from (9) and (1 1). | 

4.3. Implementation oj1V\ a Simplified Algorithm $ 

As it stands, iV is hardly an efficient algorithm; substitutions are applied too often. 
It was formulated to aid the proof of soundness. We now present a simpler algorithm $ 
which simulates in a precise sense. 
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# differs from #" in two ways. First, we adopt an idea familiar in the literature on 
resolution-based theorem-proving systems, in which substitutions are composed, but 
only applied when it is essential to do so. Second, we take advantage of the fact that what 
is often needed in practice from a well-typing algorithm is not the whole type assignment/, 
but only the type assigned to / itself. 

In fact f builds only one substitution, called E, which is idempotent— that is, EE = E 
—which is to say that if f} e Eot, then J5J8 = /?. This substitution is held in a program 
variable (called E) global to f y and f works by transforming E. In place of the unification 
function ^, f calls a unification procedure UNIFY which delivers no result but side- 
effects the variable E. We assume that °U and UNIFY are related as follows: of E and E r 
are the values of E before and after the command 

UNIFY(a, r) 

and if 

V{Ea, Er) = U 

then 

« = UE. 

Thus, applying UNIFY to types a and r in the presence of E corresponds to applying 
°U to types Eg and Er; a and r may be thought of as implicit types standing for the explicit 
types which would be gained by applying the "explicating" substitution E (the idem- 
potency of E means that further explication is unnecessary). The effect of UNIFY (if 
successful) is to generate the new explicating substitution E\ Ji will similarly handle an 
implicit typed prefix />, which can be explicated when necessary by applying E. We 
assume that J has local variables p, a, and o\ whose values are implicit types, and 
generates its result in a fourth variable r. 

Assuming an initial idempotent £, # is given a typed prefix p and an expression / 
such that Ep is standard and p \f is a pe (i.e., all free identifiers in / are bound in p). 
Here is the algorithm: 

Algorithm f 

S(PJ) = T > where 

(i) If /is x, then: 

If Xx c or fix x a is active in p, r : = a. 
If ^ a is active in j>, r := [pi/ac^Ea, where 
atf are the generic type variables of let x Ea in Ep> 
and jS f are new variables. 

(ii) If/ is (&) then: 

p:= S(?> f(P>&> 
UNIFY (p, ct -> £); (£ new) 



TYPE POLYMORPHISM 



371 



(iii) If / is (if d then e else e') y then: 

UNIFY (p )t0 ); 

UNIFY(a, a');r := a 

(iv) If/ is (A# • d), then: 

p := /(# ■ Xx v . <0; new ) 

r : ~ j3 -■> p 

(v) If / is (/be x • d), then: 

P : = ' *0 , <ty 0 3 new ) 
UNIFY(/3, P );r :=j8 

(vi) If/ is (/eZ at = ^ m e) then: 

p == /(ft — /CF • let x » > 

t :== a. | 

What is the simulation relation between f and #~ ? It is simply expressed by the 
following proposition, whose proof we omit, since it is an easy structural induction 
involving few of the subtleties which we encountered in the soundness theorem. 

Proposition 7. Let p\f be a pe, E be idempotent, and Ep be standard. Then f(p, f) 
succeeds ( producing r and a new value E' for E) iff 1i\Ep, f) succeeds ( producing T andf T ), 
and moreover if both succeed 

(A) E' - TE, 

(B) EV - r. 

Thus the type produced by $ y when explicated, is exactly that ascribed to / by 
In practice, E may be efficiently represented by a table INST of variable-type pairs, 
representing those variables which have hitherto been instantiated. The effect of UNIFY 
is merely to add some entries to INST, representing instantiation of previously un- 
instantiated variables. The substitution E represented by INST is given recursively as 
follows 

E(i) = i (basic types), 

E(a) = E(p) if (a, p) G INST for some p, 

— a otherwise, 
E(a -> r) = Ea -> Et. 

In fact, in the extended version of $ implemented for ML, which is written in LISP, 
INST itself is represented by a property (in the LISP sense) INSTANCE of type variables. 
Each type variable a has p as its INSTANCE property value, if (a, p) e INST for some p; 
otherwise the property value is NIL. 
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5. Types in Extended Languages 

We now consider some extensions of our language, and how our results may be 
strengthened to apply to them. 

(1) As we said in the introduction, the addition of extra (primitive) type operators 
such as X (Cartesian product), + (disjoint sum) and list (list forming), causes no 
difficulty. Together with these are the primitive type operators in the language ML. 
For X one has the standard polymorphic functions 

pair: a -> /? — ► (a X /?) (one could add the syntax (e, e') for pair (e)(e'))> 
fst: a X p -> a, 
snd: a X ft 

For +, one has 

inl: a -> a + /?, inr: -> a + j8 (left and right injections), 

outl: a + j8 a, outr: a + j8 -> £ (left and right projections), 

isl: <* + £ — > £00/, isr: oi + -> Z>oo/ (left and right discriminators) 

with natural interpretations. For list, one has the standard list-processing functions 
mentioned in Section 2. Notice that all members of a list must have the same type. 

With appropriate adjustment to the semantic domains, the Semantic Soundness 
Theorem extends naturally; the Syntactic Soundness Theorem goes through virtually 
without change. 

(2) Next, we consider assignable variables and assignments. One way (used in ML) 
of adding these is to allow the assignment expression form "x := e" (whose value is 
the value of <?), and the expression form "letref x = e in e'" to declare an assignable 
variable, initialized to the value of e. The first effect of these additions is a major change 
in the semantic domains, since now expressions may have side effects. Although we 
believe that a Semantic Soundness Theorem may be proved, it appears to be a cumber- 
some task. The reason for the difficulty is illustrated by considering 

\x - (y := x) 

which is an identity function with a side effect. To say that it has type a — ► a, meaning 
that whenever it is given an argument of type fx it gives a result of type ft, takes no account 
of the side effect on y. What is required is a more careful definition (in terms of the 
semantic domains) of what such functional types mean, which takes side effects into 
account. 

By contrast, it is easy enough to give well-typing rules for the two new kinds of expres- 
sion. We would extend the definition of wt by the following clauses: 

(i) (c) If letref x T is active in a standard prefix p, then p \ x r is wt. (Thus, all 
Zefrv?/-bound occurrences of x must have the same type). 
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(vii) p | (* p := e a \ is wt iff p \ e is wt, and Zefre/ # p is active in and p = a = r. 

(viii) £ | (tare/ * p = e p in e a ) T is wt iff p \ e and p • letref x p \ e f are wt, and a = r. 

It is a routine matter to extend the algorithm *W and the Syntactic Soundness Theorem 
to handle these clauses. But returning again to semantic considerations, there is a problem 
concerned with nonlocal assignments within A-abstr actions (procedures). Consider 

let g = (letref y = nil in \z • y : = cons(#, y)) 
which sets up j as a hidden (own) variable for the function g. With our rules, g obtains 
generic type a -* a list. Remembering that the value of an assignment is the value 
assigned, each call of g augments the hidden y y returning the augmented list as value. 
Now since a is generic, the expressions 

£(2), g(true) 

are both admissible within the scope of g, with types int list and bool list, respectively. 
But if they are evaluated in this order, the value of the second expression is a list whose 
two members are true and 2; it is not a list of Boolean values! 

There are at least two possible solutions to this dilemma. One is to decree that in such 
a situation a is not a generic type variable. Another, which we adopt in ML, is to forbid 
nonlocal assignments to polymorphic assignable variables within A- abstractions (proce- 
dures). Polymorphic assignable variables are still useful, for example, in programming 
iterations (while statements) which themselves can be given simple wt rules. 

I believe that the second solution, even slightly relaxed, admits a Semantic Soundness 
Theorem. The details, however, are unattractive, and I have been discouraged (particularly 
after a useful discussion with John Reynolds) from attempting to complete the proof. 
What is rather needed is a language design which pays more respect to side effects; one 
approach might be to modify PASCAL by requiring that all variables assigned in a 
procedure be listed as output parameters of the procedure. But how to combine this 
with the rather useful properties of own variables is, as far as I know, an open problem 
in language design, and a good solution would be a valuable step forward. For a recent 
promising attempt to control side effects see Reynolds [13]. 

(3) To complete the list of nontrivial extensions which we have included in ML, 
consider the declaration (possibly recursive) of a new type operator in terms of old ones. 
Such a declaration may have nonglobal scope. If it is also accompanied by the declaration 
of a set of functions over the new type operator, and the explicit definition of the type 
operator is only available in defining the set of functions (not within the whole scope of 
the new type operator), one has a version of what is currently called abstract type. In ML, 
we would define the class of binary trees whose tips are labeled by objects of arbitrary 
type as follows, using the type variable a to stand for the type of tip labels: 

absrectype a bitree = ol + (a bitree X a bitree) 

with sons(£) = ••* 

and maketree(J, t') — 

and tiptree(fl) = ••■ 
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in which only the omitted defining expressions are given access to the representation 
of bitrees. The defined functions are polymorphic, with generic types 

ol bitree (a bitree) 2 , (a bitree) 2 oc bitree, a a bitree. 

For full details of this construct, see [2]; we owe the construct partly to Lockwood Morris 
and to discussion with Jerry Schwarz. In this case the wt rules are also rather easy; we 
have not checked syntactic and semantic soundness, but suspect that there should be no 
great difficulty. 

(4) Two features which contribute a kind of polymorphism have been completely 
ignored so far. The first is coercions. The expression x : — 42, where x is a real assignable 
variable, is ill typed for us. However, there is no barrier to having the type checker 
report such instances of ill typing and allowing the compiler to receive the report and 
insert a coercion to rectify it. 

The second feature is to allow certain procedures— either standard or user defined— to 
possess more than one type. We may wish to possess int 2 — ► int and real 2 — * real y 
without of course possessing ol 2 -> a (which is the least general polytype having the two 
given types as instances). While we have not investigated the question, there appears to 
be a good possibility of superposing this feature upon our discipline. 

6. Conclusion 

We have presented a discipline of polymorphic programming which appears to be 
practically useful, and have given a rather simple type-checking algorithm. In a restricted 
language we have shown that this algorithm can be proved correct (the proof was factored 
into two Soundness Theorems). Though much work remains to be done, we hope to 
have made the point that the practice of type checking can and should by supported by 
semantic theory and proof. 
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